Systems and methods for determining available providers

ABSTRACT

Systems and methods for determining available providers is disclosed. One embodiment includes communicating with a plurality of third party data storage units, at least one of the plurality of third party data storage units comprising user preference data for a vehicle, retrieving the user preference data from a remote location, and facilitating storage of the user preference data. Some embodiments include utilizing the user preference data to predict a likely current destination and providing, by a vehicle computing device, data related to the likely current destination to a user.

TECHNICAL FIELD

Embodiments described herein generally relate to determining availableproviders and, more specifically, to determining the location of and/orrouting to a way-point.

BACKGROUND

Navigation systems have been implemented in-vehicles, such asautomobiles, to great success. Current vehicle navigation systems havebeen utilized for routing to a destination that the user manually inputsinto the system. While these current systems have proven beneficial,oftentimes a vehicle user does not wish to start the vehicle navigationeach time the user enters the vehicle. In instances where the usergenerally knows a route to reach the destination, users often do notwish to utilize the navigation system. Additionally, oftentimes, thenavigations are static and cannot dynamically provide routing based onuser actions.

SUMMARY

Systems and methods for determining available providers are described.One embodiment of a method includes communicating with a plurality ofthird party data storage units, at least one of the plurality of thirdparty data storage units comprising user preference data for a vehicle,retrieving the user preference data from a remote location, andfacilitating storage of the user preference data. Some embodimentsinclude utilizing the user preference data to predict a likely currentdestination and providing, by a vehicle computing device, data relatedto the likely current destination to a user.

In another embodiment, a system for determining available providersincludes a memory component that stores logic that, when executed by acomputing device, causes the computing device to determine a destinationof a vehicle, determine a fuel level of the vehicle at a current time,and determine, from the destination and the fuel level at the currenttime, an approximate location that the fuel level will pass below apredetermined threshold. The logic may also cause the system todetermine a preferred fuel station brand for a user, determine a fuelstation that is the preferred fuel station brand and is within apredetermined distance from the approximate location, provide the fuelstation location to the user and an option to route the vehicle to thefuel station, and provide vehicle routing data to the fuel station.

In yet another embodiment, a vehicle for determining available providersincludes a vehicle computing device that stores logic that, whenexecuted by the vehicle computing device, causes the vehicle computingdevice to determine a route to a destination for the vehicle, determinea desired meal time of a user in the vehicle, and determine anapproximate speed of the vehicle to the destination. In someembodiments, the logic causes the vehicle computing device to predict anapproximate location for the vehicle at the desired meal time, determinea preferred restaurant brand for the user, and determine a restaurantalong the route that is the preferred restaurant brand and is at adistance from the vehicle such that the vehicle will arrive at therestaurant within a predetermined time of the desired meal time, asdetermined from the approximate speed. In still some embodiments, thelogic causes the vehicle computing device to provide the restaurantlocation to the user and an option to route the vehicle to therestaurant and provide vehicle routing to the restaurant.

These and additional features provided by the embodiments of the presentdisclosure will be more fully understood in view of the followingdetailed description, in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The embodiments set forth in the drawings are illustrative and exemplaryin nature and not intended to limit the disclosure. The followingdetailed description of the illustrative embodiments can be understoodwhen read in conjunction with the following drawings, where likestructure is indicated with like reference numerals and in which:

FIG. 1 schematically depicts a network environment for implementing oneor more of vehicle access, scheduling, and/or routing options, accordingto embodiments disclosed herein;

FIG. 2 schematically depicts a vehicle computing device, according toembodiments disclosed herein;

FIG. 3 schematically depicts a vehicle interior with routing system,according to embodiments disclosed herein;

FIG. 4 depicts a vehicle authentication interface for determining adriver in a vehicle, according to embodiments disclosed herein;

FIG. 5 depicts a vehicle geographical interpretation interface forproviding an option to determine user settings, according to embodimentsdisclosed herein;

FIG. 6 depicts a vehicle menu interface for providing a plurality ofmenu options, according to embodiments disclosed herein;

FIG. 7 depicts a vehicle schedule interface for providing a remotelystored user schedule, according to embodiments disclosed herein;

FIG. 8 depicts a vehicle event interface for providing events and actionitems, according to embodiments disclosed herein;

FIG. 9 depicts a vehicle reminder interface for providing a reminderfrom a remotely stored user schedule, according to embodiments disclosedherein;

FIG. 10 depicts a vehicle routing interface for routing to an event,according to embodiments disclosed herein;

FIG. 11 depicts another vehicle routing interface for routing to anaction item, according to embodiments disclosed herein;

FIG. 12 depicts another vehicle reminder interface for providing areminder to an event that is associated with an accessory, according toembodiments disclosed herein;

FIG. 13 depicts a vehicle settings interface for providing options toone or more functional aspects of the vehicle, according to embodimentsdisclosed herein;

FIG. 14 depicts another vehicle settings interface for providing optionsto one or more non-functional aspects of the vehicle, according toembodiments disclosed herein;

FIG. 15 depicts a vehicle preference interface for providing options forpreferred fuel station brands, according to embodiments disclosedherein;

FIG. 16 depicts another vehicle preference interface for providingoptions for preferred restaurant brands, according to embodimentsdisclosed herein;

FIG. 17 depicts a vehicle weather interface for providing an alternaterouting option, according to embodiments disclosed herein;

FIG. 18 depicts a vehicle fuel reminder interface for providing arouting option to a way-point, such as a fuel station, according toembodiments disclosed herein;

FIG. 19 depicts a vehicle restaurant reminder interface for providing arouting option to a way-point, such as a restaurant, according toembodiments disclosed herein;

FIG. 20 depicts a vehicle way-point interface for providing a useroption to add a way-point as a preferred restaurant brand, according toembodiments disclosed herein;

FIG. 21 depicts a web vehicle sign-in interface for providing vehicleinformation, according to embodiments disclosed herein;

FIG. 22 depicts a web vehicle options interface for selecting one ormore options for the vehicle, according to embodiments disclosed herein;

FIG. 23 depicts a web vehicle settings interface for providing optionsto one or more functional aspects of the vehicle, according toembodiments disclosed herein;

FIG. 24 depicts another web vehicle settings interface for providingoptions to one or more non-functional aspects of the vehicle, accordingto embodiments disclosed herein;

FIG. 25 depicts a web vehicle preferred way-point interface forproviding options for a preferred restaurant brand, according toembodiments disclosed herein;

FIG. 26 depicts another vehicle preferred way-point interface forproviding options for a preferred fuel station, according to embodimentsdisclosed herein;

FIG. 27 depicts a web vehicle schedule interface for linking a remotelystored user schedule with the vehicle, according to embodimentsdisclosed herein;

FIG. 28 depicts a web vehicle weather interface for providing weatheroptions for the vehicle, according to embodiments disclosed herein;

FIG. 29 depicts a flowchart for providing customized communication withan authorized vehicle user, according to embodiments disclosed herein;

FIG. 30 depicts a flowchart for adjusting functional and/ornon-functional aspects of a vehicle, according to embodiments disclosedherein;

FIG. 31 depicts a flowchart for uploading user preference data from avehicle to a remote computing device, according to embodiments disclosedherein;

FIG. 32 depicts a flowchart for implementing a functional and/ornon-functional aspect of the vehicle, according to embodiments disclosedherein;

FIG. 33 depicts a flowchart for sending user settings to a rentalvehicle, according to embodiments disclosed herein;

FIG. 34 depicts a flowchart for an event reminder, according toembodiments disclosed herein;

FIG. 35 depicts a flowchart for providing routing to a predeterminedlocation, according to embodiments disclosed herein;

FIG. 36 depicts a flowchart for providing routing information to anaccessory that is related to an event, according to embodimentsdisclosed herein;

FIG. 37 depicts a flowchart for providing a likely point of interestand/or alternate route to a user, according to embodiments disclosedherein;

FIG. 38 depicts a flowchart for providing vehicle routing to away-point, such as a fuel station, according to embodiments disclosedherein;

FIG. 39 depicts a flowchart for providing vehicle routing to away-point, such as a restaurant, according to embodiments disclosedherein; and

FIG. 40 depicts a flowchart for providing an alternate vehicle route dueto weather, according to embodiments disclosed herein.

DETAILED DESCRIPTION

Embodiments disclosed herein include systems and methods forcommunicating with a vehicle user. Also included are systems and methodsfor a vehicle smart calendar, and systems and methods for determiningavailable providers. Accordingly, some embodiments may be configured toprovide a user with access to a vehicle and import remotely storedsettings into the vehicle system. The stored settings may includefunctional and/or non-functional aspects of the vehicle, which may beimplemented as described herein. Similarly, some embodiments may beconfigured to utilize a remotely (or locally) stored user schedule toprovide reminders, routing, and/or other information to a vehicle user.Further embodiments may be configured to provide routing to way-pointsbased on previously determined user preferences, such as restaurantbrands, fuel station brands, service station brands, etc. The systemsand methods for incorporating the same will be described in more detailbelow with specific reference to the appended drawings.

Referring now to FIG. 1, an embodiment of a system 100 that includes avehicle 102 is schematically depicted. It is noted that, while thevehicle 102 is depicted as an automobile, the vehicle 102 may be anypassenger or non-passenger vehicle such as, for example, a terrestrial,aquatic, and/or airborne vehicle. The vehicle 102 may include a vehiclecomputing device 114 and/or other components. For example, the vehiclecomputing device 114 may include a communication path 104 that providesdata interconnectivity between various vehicle modules disposed withinthe vehicle 102. Accordingly, the communication path 104 communicativelycouples any number of vehicle modules with one another, and allows thevehicle modules to operate in a distributed computing environment.Specifically, each of the vehicle modules can operate as a node that maysend and/or receive data. In some embodiments, the communication path104 may include a conductive material that permits the transmission ofelectrical data signals to processors, memories, sensors, and actuatorsthroughout the vehicle 102. In another embodiment, the communicationpath 104 can be a bus, such as for example a LIN bus, a CAN bus, a VANbus, and the like. In further embodiments, the communication path 104may be wireless and/or an optical waveguide. Components that arecommunicatively coupled may include components capable of exchangingdata signals with one another such as, for example, electrical signalsvia conductive medium, electromagnetic signals via air, optical signalsvia optical waveguides, and the like.

The vehicle 102 generally includes input/output hardware 108communicatively coupled with the communication path 104. Theinput/output hardware 108 serves as an interconnection between a humandriver and the vehicle 102. The input/output hardware 108 can be anydevice capable of transforming mechanical, optical, and/or electricalsignals into a data signal capable of transmission via the communicationpath 104. Moreover, the input/output hardware 108 can include any devicecapable of transforming a data signal into a mechanical, optical, and/orelectrical output. Each individual component of the input/outputhardware 108 may include one or more processors and one or morememories. In some embodiments, each individual component of theinput/output hardware 108 can omit a processor and/or a memory.Accordingly, it is noted that, while specific components are describedherein as including a processor and/or a memory, the embodimentsdescribed herein should not be so limited.

In some embodiments, the input/output hardware 108 can include a tactileinput device 110 such as, for example, a button, a switch, a knob, orthe like. The physical motion of the tactile input device 110 can bedigitized into a data signal that can be transmitted to a vehiclecomponent. The input/output hardware 108 can further include amicrophone 120 for receiving input from a user. The microphone 120 canbe any sensor that transforms mechanical vibrations into a data signal.A sensor may include any device that measures a physical quantity andconverts it into a data signal, which is correlated to the measuredvalue of the physical quantity, such as, for example, an electricalsignal, an electromagnetic signal, an optical signal, a mechanicalsignal, or the like.

The input/output hardware 108 may also include a speaker 122 fortransforming data signals into mechanical vibrations. It should be notedthat a signal may include a waveform (e.g., electrical, optical,magnetic, mechanical or electromagnetic), such as direct current (DC),alternating current (AC), sinusoidal-wave, triangular-wave, square-wave,vibration, and the like, capable of traveling through a medium.

Similarly, the input/output hardware 108 can include one or moredisplays for visually presenting data. The display can be locatedanywhere in the passenger compartment of the vehicle 102 and can includeany medium capable of transmitting a visual output such as, for example,a cathode ray tube, light emitting diodes, liquid crystal displays,plasma displays, or the like. Each of the one or more displays can be atouch screen that, in addition to providing visual information, detectsthe presence and location of a tactile input upon a surface of oradjacent to the display. Accordingly, each display can receivemechanical input directly upon the optical output provided by thedisplay.

In some embodiments, the vehicle 102 may include a processor 132communicatively coupled with a memory component 134. The memorycomponent 134 may be configured to store one or more pieces of logic, asdescribed in more detail below. It is also noted that, while the vehiclecomputing device 114 includes a single processor 132 and a single memorycomponent 134; this is merely one example. For example, the vehicle 102and/or vehicle computing device 114 may include a plurality ofcomponents each having one or more memories and/or processors that arecommunicatively coupled with one or more of the other components. Thus,the embodiments described herein may utilize a distributed computingarrangement to perform any portion of the logic described herein.

According to the embodiments described herein, the processor 132 mayinclude any device capable of executing machine-readable instructions,which may be stored on a non-transitory computer-readable medium.Accordingly, each processor may include a controller, an integratedcircuit, a microchip, a computer, and/or any other computing device. Thememory described herein may include RAM, ROM, a flash memory, a harddrive, and/or any device capable of storing machine-readableinstructions.

Embodiments of the present disclosure include logic that includesmachine-readable instructions and/or an algorithm written in anyprogramming language of any generation (e.g., 1GL, 2GL, 3GL, 4GL, and/or5GL) such as, e.g., machine language that may be directly executed bythe processor, assembly language, object-oriented programming (OOP),scripting languages, microcode, etc., that may be compiled or assembledinto machine readable instructions and stored on a machine readablemedium. Similarly, the logic and/or algorithm may be written in ahardware description language (HDL), such as logic implemented viaeither a field-programmable gate array (FPGA) configuration or anapplication-specific integrated circuit (ASIC), and their equivalents.Accordingly, the logic may be implemented in any conventional computerprogramming language, as pre-programmed hardware elements, and/or as acombination of hardware and software components.

Moreover, the logic can be distributed over various components that arecommunicatively coupled over a network 160 that may include one or morecellular networks, satellite networks and/or computer networks such as,for example, a wide area network, a local area network, personal areanetwork, a global positioning system and combinations thereof.Accordingly, the vehicle 102 can be communicatively coupled to thenetwork 160 via wires, via a wide area network, via a local areanetwork, via a personal area network, via a cellular network, via asatellite network, etc. Suitable local area networks may include wiredEthernet and/or wireless technologies such as, for example, wirelessfidelity (Wi-Fi). Suitable personal area networks may include wirelesstechnologies such as, for example, IrDA, Bluetooth, Wireless USB,Z-Wave, ZigBee, and/or other near field communication protocols.Suitable personal area networks may similarly include wired computerbuses such as, for example, USB and FireWire. Suitable cellular networksinclude, but are not limited to, technologies such as LTE, WiMAX, UMTS,CDMA, and GSM. Thus, any components of the vehicle 102 can utilize oneor more network 160 components to transmit signals over the Internet orWorld Wide Web.

In some embodiments, the vehicle 102 includes network interface hardware150 for communicatively coupling the vehicle 102 with the network 160.The network interface hardware 150 can be communicatively coupled to thecommunication path 104 and can be any device capable of transmittingand/or receiving data via the network 160. Accordingly, the networkinterface hardware 150 can include an antenna and/or other communicationtransceiver for sending and/or receiving any wired or wirelesscommunication. For example, the network interface hardware 150 mayinclude an antenna, a modem, LAN port, Wi-Fi card, WiMax card, mobilecommunications hardware, near-field communication hardware, satellitecommunication hardware and/or any wired or wireless hardware forcommunicating with other networks and/or devices.

The network 160 can communicatively couple the vehicle 102 with otherdevices in a flexible client-server relationship. More specifically, thevehicle 102 may be a configured as a server to and/or a client of anydevice communicatively coupled to the vehicle 102 via the network 160.Specifically, the network 160 can be configured to enable the deliveryof cloud resources to and/or from the vehicle 102. Any devicecommunicatively coupled to the vehicle 102 can deliver a cloud resourceto the vehicle 102 via the network 160. Similarly, the vehicle 102 candeliver a cloud resource via the network 160 to any devicecommunicatively coupled to the vehicle 102. Accordingly, cloud resourcessuch as, for example, processing, storage, software, and information canbe shared via the network 160.

Referring still to FIG. 1, the network 160 may be utilized tocommunicatively couple the vehicle 102, one or more remote computingdevices 162, one or more third party remote computing devices 164, oneor more mobile phone devices 204, one or more vehicle access devices168, and one or more user community devices 170. Accordingly, each ofthese devices can be communicatively coupled to one another directly orindirectly via the network 160. For example, one or more devicescommunicatively coupled to the network 160 can operate as anintermediary to transmit data between any of the other devices.Accordingly, the network 160 can facilitate a distributed computingarrangement amongst the vehicle 102 and the other devices. Specifically,any of the devices communicatively coupled to the network 160 can sharecloud resources such that each communicatively coupled device canperform any portion of the logic described herein.

It should also be understood that while the components in FIG. 1 areillustrated as communicating through the network 160, thisrepresentation may also include instances of direct communicationbetween the vehicle 102 and a device. As an example, the vehicle accessdevice and/or mobile phone device 166 may communicate with the vehiclecomputing device 114 via a direct near field communication protocol.

As is noted above, the vehicle 102 can be communicatively coupled to theone or more devices via the network 160. Each of the one or more devicescan include one or more processors and one or more memories. The one ormore processors can execute logic to provide cloud resources to thevehicle 102 and/or any other device communicatively coupled to thenetwork 160. For example, the one or more devices can providesupplementary processing power, via relatively high powered processors,to the vehicle 102. Additionally, the one or more devices can providesupplementary data storage to the vehicle 102. Moreover, the one or moredevices can provide platforms such as, for example, a social networkingservice, news service, weather service, traffic service, map service(e.g., restaurant data, fuel station data, service station data), andany other service capable of being exchanged between a server and aclient.

The user computing device 170 may also be coupled to the network 200 andmay be configured as any portable and/or non-portable computing device,such as a personal computer, laptop computer, personal digital assistant(PDA), mobile phone, etc. In some embodiments, the user computing device170 may be implemented as the mobile phone device 166. Regardless, theuser computing 104 a may include a memory component that stores logicthat is similar to the logic stored by the vehicle computing device 134,but configured for slightly different functionality. As an example,logic stored by the user computing device may be configured to cause theuser computing device 170 to provide interfaces and receive user inputrelated to providing access to the vehicle 102. Similarly, this logicmay be configured to cause the user computing device 170 to provideinterfaces and options related to user schedules that may be utilized inthe vehicle 102. The logic may be similarly configured to cause the usercomputing device 170 to provide interfaces and/or options forconfiguring user vehicle routing preferences, as discussed in moredetail, below.

Similarly, the remote computing device 162 may include a server and/orother computing device for providing information to the vehiclecomputing device 114 and/or the vehicle computing device 114. In someembodiments, the remote computing device 162 may include a memorycomponent for storing logic that is similar to the other logic discussedabove, but may be configured for different functionality. Morespecifically, the logic stored by the remote computing device 162 may beconfigured to remotely store and provide vehicle access data, userscheduling data, and/or user routing preference data. Thus, the remotecomputing device 162 may be configured for “cloud” storage of datadescribed herein.

Also included is the third party remote computing device 164. The thirdparty remote computing device 164 may be configured to compile and/orstore third party data, such as news, weather reports, traffic reports,restaurant data, fuel station data, service station data, etc. Asdescribed in more detail below, this data may be accessed by the vehiclecomputing device 114 for performing the functionality described herein.

FIG. 2 depicts a vehicle computing device 114, according to oneembodiment disclosed herein. In the illustrated embodiment, the vehiclecomputing device 114 includes a processor 132, input/output hardware108, network interface hardware 150, a data storage component 236 (whichstores routing 238 a, user data 238 b, and/or other data), and thememory component 134. The memory component 134 may be configured asvolatile and/or nonvolatile memory and as such, may include randomaccess memory (including SRAM, DRAM, and/or other types of RAM), flashmemory, secure digital (SD) memory, registers, compact discs (CD),digital versatile discs (DVD), and/or other types of non-transitorycomputer-readable mediums. Depending on the particular embodiment, thesenon-transitory computer-readable mediums may reside within the vehiclecomputing device 114 and/or external to the vehicle computing device114.

Additionally, the memory component 134 may store operating logic 242,access logic 244 a, scheduling logic 244 b, and routing logic 244 c. Theaccess logic 244 a, the scheduling logic 244 b, and the routing logic244 c may each include a plurality of different pieces of logic, each ofwhich may be embodied as a computer program, firmware, and/or hardware,as an example. A local interface 246 is also included in FIG. 2 and maybe implemented as a bus or other communication interface to facilitatecommunication among the components of the vehicle computing device 114.

As discussed above, the processor 132 may include any processingcomponent operable to receive and execute instructions (such as from thedata storage component 236 and/or the memory component 134). Theinput/output hardware 108 may include and/or be configured to interfacewith a monitor, positioning system, keyboard, mouse, printer, imagecapture device, microphone, speaker, gyroscope, compass, globalpositioning system (GPS), seatbelt sensor, user sensor, fuel sensor, aspeed sensor, volume sensor, a door lock sensor, a passenger sensor(such as a weight sensor, seat sensor, etc.), a proximity sensor such asa radio frequency identifier (RFID) sensor, communication device (e.g.,for cellular, internet, and/or other communications), and/or otherdevice for receiving, sending, and/or presenting data as describedherein. The network interface hardware 150 may include and/or beconfigured for communicating with any wired or wireless networkinghardware, including an antenna, a modem, LAN port, wireless fidelity(Wi-Fi) card, WiMax card, mobile communications hardware, and/or otherhardware for communicating with other networks and/or devices. From thisconnection, communication may be facilitated between the vehiclecomputing device 114 and other computing devices.

The operating logic 242 may include an operating system and/or othersoftware for managing components of the vehicle computing device 114.Similarly, as discussed above, the access logic 244 a may reside in thememory component 134 and may be configured to cause the processor 132 toprovide the access functionality described herein. Similarly, thescheduling logic 244 b may be utilized to provide the schedulingfunctionality described herein. The routing logic 244 c may cause thevehicle computing device 114 to provide the routing functionality, asdescribed herein.

It should be understood that while the components in FIG. 2 areillustrated as residing within the vehicle computing device 114, this ismerely an example. In some embodiments, one or more of the componentsmay reside external to the vehicle computing device 114. It should alsobe understood that, while the vehicle computing device 114 in FIG. 2 isillustrated as a single device, this is also merely an example. In someembodiments, the access logic 244 a, the scheduling logic 244 b, and/orthe routing logic 244 c may reside on different devices.

Additionally, while the vehicle computing device 114 is illustrated withthe access logic 244 a, the scheduling logic 244 b, and the routinglogic 244 c as separate logical components, this is also an example. Insome embodiments, a single piece of logic may cause the vehiclecomputing device 114 to provide the described functionality.

FIG. 3 depicts a vehicle interior 300 with a routing system, accordingto embodiments disclosed herein. As illustrated, the vehicle interior300 may include a console display 350 and a dash display 352. Theconsole display 350 may be configured to provide one or more interfaces,as disclosed herein, related to user preferences, routing, music, and/orother data. The dash display 352 may similarly be configured to provideone or more interfaces, but often the data provided in the dash display352 is abbreviated from the data provided by the console display 350.Regardless, at least a portion of the interfaces depicted and describedherein may be provided on either or both the console display 350 and thedash display 352.

FIG. 4 depicts a vehicle authentication interface 400 for determining anidentity of a driver in a vehicle 102, according to embodimentsdisclosed herein. More specifically, the vehicle 102 may be configuredto detect a user attempting to enter the vehicle 102 via the vehicleaccess device 168 (FIG. 1). This attempt may be in the form of a fobsignal, key turn, and/or other access request. Assuming that the vehicleaccess device 168 is valid, the user may be permitted access to thevehicle 102.

The vehicle 102 may additionally detect a first identifying signal fromthe mobile phone device 166 (FIG. 1). The mobile phone device 166 maycommunicate a user identifier to the vehicle 102. The vehicle 102 maythen access local storage to determine the identity of the user. If dataregarding the user is not stored locally, the vehicle 102 maycommunicate with the remote computing device 162 (or the mobile phonedevice 166) for the user data. Regardless, once the user is identified,the vehicle 102 may access locally and/or remotely stored userpreferences for functional and/or non-functional aspects of the vehicle102.

However, oftentimes two or more users seek access to the vehicle 102,each with their own mobile phone device 166. The vehicle 102 may thusreceive a first identifying signal from a first mobile phone device 166and a second identifying signal from a second mobile phone device 166.Accordingly, the vehicle 102 may determine which one of the users is thedriver of the vehicle 102. As illustrated in FIG. 4, this determinationmay be made via the vehicle authentication interface 400. In the vehicleauthentication interface 400, the vehicle computing device 114 mayprovide a request for the users to identify which is the driver, asillustrated in options 450 and 452. Upon selection of one of the options450, 452, the user preference for the selected driver will be applied tothe functional aspects of the vehicle 102. The functional aspects of thevehicle 102 may include a driver seat position setting, a languagesetting, a units setting, an avatar setting, a minor position setting, asteering wheel setting, a radio setting, a heat ventilation airconditioning (HVAC) system setting, a previous destination setting, etc.Similarly, non-functional aspects of the vehicle 102 may also beimplemented. Non-functional aspects may include a playlist setting, apreferred music setting, a schedule setting, an action item setting, anews setting, a waypoint setting, such as a restaurant setting, a fuelstation setting, etc. Additionally, functional and non-functionalaspects of the vehicle 102 may be customized for the non-driver users,such as passenger seat position, HVAC system setting, music, images,etc.

It should be understood that while in some embodiments the driver may bedetermined from the vehicle authentication interface 400, this is merelyan example. In some embodiments, a priority list may be implemented suchthat if a first user and a second user enter the vehicle 102, the firstuser is always the driver. Similarly, in some embodiments, adetermination of the origin of the mobile phone device 166 may determinewhich user is the driver. As an example, if the vehicle 102 determinesthat the first user is approaching the driver side door and the seconduser is approaching the passenger side door, a determination may be madethat the first user is the driver. Other mechanisms for determiningwhich user is the driver may also be implemented.

It should also be understood that the functional and/or non-functionalaspects of the vehicle 102 may be determined in any number of differentways. As an example, if a user adjusts a seat position, selects a radiostation, and/or performs other action within the vehicle 102 (or othervehicle), this setting may be stored. Storage of the setting may beautomatic and/or user initiated storing. The setting may be storedlocally on the vehicle computing device 114 and/or at the remotecomputing device 162. Similarly, one or more of the settings may bemanually set using the console display 350. The user may manually keysettings into the vehicle computing device 114 for local and/or remotestorage. The user may similarly manually enter user settings into theuser computing device 170 (and/or mobile phone device 166) for storageon the user computing device 170, remote computing device 162, and/orvehicle computing device 114. Yet another mechanism for determining userpreferences is via predictive capabilities of the vehicle computingdevice 114, the user computing device 170, the mobile phone device 166,and/or the remote computing device 162.

FIG. 5 depicts a vehicle geographical interpretation interface 500 forproviding an option to determine user settings, according to embodimentsdisclosed herein. As illustrated, the vehicle geographicalinterpretation interface 500 may be configured to provide an option todetect functional and/or non-functional aspects of the vehicle 102. Asan example, when the vehicle computing device 114 determines that thevehicle 102 is currently in a different geographic region, the vehiclecomputing device 114 may determine which settings may be regionallybased. Regionally based settings may include terrestrial radio stations,climate control, seat heaters/coolers, etc. In the example of FIG. 5,the vehicle computing device 114 determined that the radio stations areregional. Based on the user's previously set radio stations, the vehiclecomputing device 114 may determine comparable radio stations for thecurrent geographical location. The vehicle geographical interpretationinterface 500 may then provide a first option 550 that permits thevehicle computing device 114 to determine preferred radio stations forthis geographic region. The second option 552 denies the vehiclecomputing device 114 permission to make this determination.

FIG. 6 depicts a vehicle menu interface 600 for providing a plurality ofmenu options, according to embodiments disclosed herein. As illustrated,the vehicle menu interface 600 may provide a plurality of options forthe vehicle 102. As an example, once the users, driver, and/or regionalsettings are determined, the vehicle menu interface 600 may be provided.If no such preliminary determinations are made, the vehicle computingdevice 114 may default to the vehicle menu interface 600. The vehiclemenu interface 600 includes a plurality of options, such as a directionsoption 650, a calendars option 652, a users option 654, a settingsoption 656, a radio option 658, a functional aspects option 660, and anon-functional aspects option 662.

In response to selection of the directions option 650, the user may bepresented with one or more interfaces for manually entering adestination for vehicle routing. In response to selection of thecalendars option 652, one or more remotely and/or locally stored userschedules may be provided. In response to selection of the users option654, options related to users of the vehicle 102 may be provided. Inresponse to selection of the settings option 656, vehicle settings maybe provided to the user for viewing and/or editing. In response toselection of the radio option 658, radio settings and/or channels may beprovided. In response to selection of the functional aspects option 660,functional aspect settings may be provided to the user for viewingand/or editing. In response to selection of the non-functional aspectsoption 662, non-functional aspect settings may be provided to the userfor viewing and/or editing.

FIG. 7 depicts a vehicle schedule interface 700 for providing a remotelystored user schedule, according to embodiments disclosed herein. Asillustrated, in response to selection of the calendars option 652 fromFIG. 6, the vehicle schedule interface 700 may be provided. The calendardepicted in the vehicle schedule interface 700 may be retrieved from aremotely stored user schedule and may include one or more events and/oraction items for the user. By selecting one or more of the days in thevehicle schedule interface 700, the vehicle computing device 114 mayprovide events and/or action items that the user has scheduled for thatday. Additionally, an add entry option 750 may be provided for a user toadd an event and/or action item. A close option 752 may be provided forreturning to the vehicle menu interface 600 from FIG. 6.

FIG. 8 depicts a vehicle event interface 800 for providing events andaction items, according to embodiments disclosed herein. The vehicleevent interface 800 may be provided in response to selection of a daythat is displayed in the vehicle schedule interface 700 from FIG. 7. Asillustrated, the vehicle event interface 800 may provide times,descriptions, and/or locations of events. Action items, which may nothave a designated time or location for completion, may also be provided.In response to a user selecting one of the events and/or action items,options to view more details, edit, and/or delete the event may beprovided. A return option 850 is also provided for returning to thevehicle menu interface 600 from FIG. 6.

FIG. 9 depicts a vehicle reminder interface 900 for providing a reminderfrom a remotely stored user schedule, according to embodiments disclosedherein. As illustrated, when a determination is made that an event timeis approaching, the vehicle computing device 114 may notify the userwith the vehicle reminder interface 900. More specifically, if the userschedule is remotely stored, the remote computing device 162 and/or themobile phone device 166 may send a request to the vehicle computingdevice 114 for providing the reminder. Similarly, in some embodiments,the vehicle computing device 114 may store the reminder locally and mayprovide the reminder at a designated time. The designated time may bedetermined based on a user selected predetermined time and/or based onthe current location of the vehicle 102 with respect to the event. As anexample, if the vehicle 102 is 30 minutes away from the event, thevehicle computing device 114 may be configured to provide the reminder30 minutes, plus a predetermined time before the event. This allows theuser to reach the event prior to the event time. Additionally, whileFIG. 9 depicts an event reminder, similar interfaces may be provided foran action item reminder and/or other reminders.

Similarly, in some embodiments, the vehicle computing device 114 maydetermine that an action item could be efficiently completed based onthe current time, the time of an upcoming event, the location of thevehicle 102, the location of the event, and the location of the actionitem. As such, the vehicle computing device 114 may calculate a time tocomplete the action item, remind the user of the action item, andprovide the reminder at a time that will allow both tasks to becompleted.

Also included in the vehicle reminder interface 900 is a route option950 and an ignore option 952. In response to selection of the routeoption 950, the vehicle computing device 114 may determine a route fromthe current location to the event and may provide routing guidance tothe event. In response to selection of the ignore option 952, thevehicle computing device 114 may return to the vehicle menu interface600 from FIG. 6.

FIG. 10 depicts a vehicle routing interface 1000 for routing to anevent, according to embodiments disclosed herein. As illustrated, inresponse to selection of the route option 950 from FIG. 9, the vehiclecomputing device 114 may determine a route to the event and provide thatroute to the user. Additionally, depending on third party traffic data,third party weather data, third party road condition data, etc. theestimated time of arrival for the vehicle 102 may change. As such, thevehicle computing device 114 may provide updates to the estimated timefor arrival. If the vehicle computing device 114 determines that thevehicle 102 will likely be late to the event, a contact option 1050 maybe provided, so that the user may inform the other parties to the eventof the estimated time of arrival.

FIG. 11 depicts another vehicle routing interface 1100 for routing to anaction item, according to embodiments disclosed herein. As illustrated,if the vehicle computing device 114 determines, based on the vehiclelocation, an action item location, current traffic, weather, and/orother information, that there is adequate time to complete an actionitem and may provide a route to the action item. Also included in thevehicle routing interface 1100 are a route to action item option 1150and a route to destination option 1152. By selecting the route to actionitem option 1150, the vehicle computing device 114 may provide routingguidance to the action item. Upon completing the action item, thevehicle computing device 114 may then route the user to the event.

It should be understood that an action item may or may not include atime of performance or a location. As such, the vehicle computing device114 and/or other computing device described herein may be configured todetermine a location and/or time for completing the action item. As anexample, if the action item is “pick up milk,” the vehicle computingdevice 114 may determine from the text that milk is the object of theaction item. The vehicle computing device 114 may additionally determinethat milk may be purchased at a grocery store, fuel station, drug store,etc. The vehicle computing device 114 may then determine a location thatis convenient for the user to carry out the action item, based on thecurrent location of the vehicle 102, the location of other events and/orthe location of other action items. Additionally, some embodiments, mayallow the user to provide preferred way-point brands, as described inmore detail below. Referring to the example above, if the user prefers aparticular type of store for purchasing milk (e.g., a grocery store),this indication may be provided by the user and/or determined from useractions.

FIG. 12 depicts another vehicle reminder interface 1200 for providing areminder to an event that is associated with an accessory, according toembodiments disclosed herein. As illustrated, some events and/or actionitems may be associated with an accessory. As an example, if the eventis a golf match, the vehicle computing device 114 may determine that theuser will wish to bring her golf clubs to the golf course. The vehiclecomputing device 114 may determine that the event is associated with anaccessory through a user indication, through past events, and/or througha logical determination. As an example, if the user has previouslytraveled to golf courses for similar events and the user stopped toretrieve her golf clubs, the vehicle computing device 114 may utilizethis historical information to determine that golf clubs are likelydesired for this event. Similarly, if the destination is a golf courseand the event mentions the word “golf,” “green,” “play,” and/or othersimilar term, the vehicle computing device 114 may determine that golfclubs are desired.

Regardless of the mechanism for determining that the event is associatedwith the event, the vehicle computing device 114 may receive apositioning signal and utilize the positioning signal to determinewhether the accessory is currently in proximity of the vehicle 102. Thisdetermination may be made through a proximity sensor, such as a radiofrequency identifier (RFID) sensor in the vehicle 102 that receives anRFID signal from the accessory, through past actions, and/or through auser indication. As such, the vehicle reminder interface 1200 includes aroute to accessory option 1250 for retrieving the accessory. Theaccessory location may be determined from past actions, a locationidentifier, and/or user input. A route to event option 1252 is alsoprovided in the vehicle reminder interface 1200 for routing the vehicle102 directly to the event.

As an example, the vehicle computing device 114 may communicate with thevehicle GPS to determine that the vehicle has arrived at a golf course.The vehicle computing device 114 may additionally communicate with theRFID sensor determine that after stopping at the golf course, the user'sgolf clubs (which may be equipped with an RFID tag) are removed from thevehicle 102. Upon the vehicle 102 leaving the golf course, the vehiclecomputing device 114 may determine that the golf clubs never returned tothe vehicle. With this information, upon determining that the user'supcoming appointment is at the golf course, the vehicle computing device114 may determine that the golf clubs are likely still at the previousgolf course. A notification and/or routing to this previous destinationmay be provided.

FIG. 13 depicts a vehicle settings interface 1300 for providingin-vehicle options to one or more functional aspects of the vehicle 102,according to embodiments disclosed herein. The vehicle settingsinterface 1300 may be provided in response to selection of thefunctional aspects option 660 from FIG. 6. As illustrated, the vehiclesettings interface 300 includes a plurality of functional options for aparticular user. Accordingly, the vehicle settings interface 1300includes a seat position option 1350, a mirror option 1352, a steeringwheel option 1354, a radio option 1356, a heating ventilation airconditioning (HVAC) option 1358, and an other option 1360.

In response to selection of one or more of the options depicted in thevehicle settings interface 1300, the vehicle computing device 114 mayprovide the current settings for that functional aspect of the vehicle102. The vehicle computing device 114 may additionally provide optionsto reset, remove, add, and/or otherwise edit the settings that areprovided.

FIG. 14 depicts another vehicle settings interface 1400 for providingin-vehicle options to one or more non-functional aspects of the vehicle102, according to embodiments disclosed herein. The vehicle settingsinterface 1400 may be provided in response to a selection of thenon-functional aspects option 662 from FIG. 6. As illustrated, thevehicle settings interface 1400 includes an images option 1450, aplaylists option 1452, a preferred music genres option 1454, a schedulesoption 1456, an action items list 1458, a news option 1460, a fuelstations option 1462, a restaurants option 1464, a communications option1468, a parental control option 1470, an other option 1472, and an alloption 1468. Other non-functional options may be provided, as well.

While the user may manually alter one or more of these non-functionalaspects of the vehicle 102, in some embodiments the vehicle computingdevice 114 may determine the non-functional aspects of the vehicle 102,based on past user settings. As an example, if a user selects an image,such as on a social media website, the vehicle computing device 114 mayrecognize that this is an image that the user prefers. Similarly, if theuser participates in “cloud storage” of music files, the vehiclecomputing device 114 may analyze the remotely stored music files anddetermine preferred music genres. As discussed above, the schedules andaction items may be determined from a remotely stored calendar, a mobilecalendar, and/or elsewhere. News, fuel stations, restaurants maysimilarly be determined based on user input and/or past actions.

As an example, the communications option 1468 may provide the user withoptions for the vehicle 102 to communicate directly with social medianetworks, cellular networks, data networks, etc. More specifically, thevehicle computing device 114 may be configured to send and receiveemails, social media messages, short message system (SMS) messages, etc.directly from the vehicle 102. Such embodiments may utilize text inputs,voice to text, and/or text to voice technologies. Similarly, otheroptions under the communications option 1468 may include options to“check in” to a location via a social media site using a communicationdirectly from the vehicle computing device 114. Contacts (via socialmedia or another source) may also be provided under the communicationsoption 1468. Options for social media status changes may be provided, aswell as trending nearby locations. Options for specials provided bynearby vendors may also be provided under the communications option1468, as well as options to contact a message sender or social mediacontact directly from the vehicle 102. Similarly, some embodimentsprovide options to provide routing inputs directly from social mediaand/or received messages.

Similarly, in some embodiments the communications option 1468 mayinclude options to determine a current location and/or destination ofthe vehicle 102. The vehicle 102 may then provide a user option to sendthat location and/or destination to a social media site. Upon selectionof the user option, the vehicle 102 may format the location and/ordestination data into a format that is compatible with a predeterminedmessaging protocol (e.g., SMS, email, FACEBOOK®, TWITTER®, etc.). Theinformation may then be sent from the vehicle 102 to a predeterminedrecipient.

Further, in some embodiments, the communications option 1468 may includeoptions for providing a vehicle profile to a social media site thatlinks with one or more user's social networking profile. When the userenters the vehicle 102 the vehicle computing device 114 may identify theuser and link the vehicle profile with that user's social networkingprofile. The vehicle profile may then communicate with the vehicle toprovide a user interface for updating status information with the socialnetworking profile.

In some embodiments, the communications option 1466 may include optionsto access user-defined data and provide this data as an overlay on avehicle display, such as the console display 350 and/or the dash display352. More specifically, contact data, crime data, trending data, etc.may be retrieved from the third party remote computing device 164. Whenthe vehicle is within a predetermined area of the geographic location,the information may be provided.

Similarly, the parental controls option 1470 may be configured toprovide smart vehicle controls by an authorized user. More specifically,the parental controls option 1470 may be configured to provide optionsto remotely monitor a position of the vehicle 102 and to receive analert when the vehicle 102 performs a predetermined action or whenpassengers in the vehicle 102 perform a predetermined action of which aparent (vehicle owner) does not approve. In some embodiments, a vehicleowner may be remotely alerted (via SMS, email, telephone call, etc.)when the vehicle 102 and/or passengers exceed preset criteria.Similarly, in some embodiments predetermined vehicle functionality maybe enabled or disabled (e.g., auto-locks of doors). In still someembodiments, an audible message may be provided to an occupant of thevehicle 102 when the action is detected.

As an example, the vehicle 102 may communicate with the remote computingdevice 162 and/or the user computing device 170 to provide location datato the owner of the vehicle. Oftentimes, the owner of the vehicle 102 isnot the user and thus the owner will wish to identify the actions thattake place in the vehicle 102. As discussed in more detail below, thevehicle computing device 114 may communicate with one or moreinput/output hardware 108 for determining various states of the vehicle102. Based on predetermined criteria regarding the states of the vehicle102, notification may be sent to the owner via a predetermined mechanismfor communication (e.g. web interface, text, email, phone call, etc.).

Examples of the permission settings that may be provided via theparental controls option 1470 may include maximum vehicle speed, maximumradio volume, rating and/or control of media (radio, video, etc.),disabling the vehicle until seatbelts are fastened, disallowing mediawithout a fastened seat belt. Similarly, monitoring and notificationoptions provided via the parental controls option 1470 may include speednotification, occupant detection, geo-fencing for vehicle locationcontrol, overall location, and driving statistics.

Similar options that may be provided within the parental controls option1470 include options to remotely monitor a position of the vehicle 102and receive an alert when the vehicle enters a predetermined area, suchas a high-crime area, child predator area, etc. Embodiments may thenaccess the third party remote computing device 164 to retrieve crimedata to determine unsafe areas. In some embodiments the vehicle ownermay create a geo-fenced area, where the owner is notified when thevehicle enters the geo-fenced area. Similarly, in some embodiments,vehicle functions may be automatically enabled (e.g., auto-locks) ordisabled (e.g., radio volume) when the vehicle enters the area. Optionsmay also be provided for users to share high-crime areas with others.

As an example, the owner of the vehicle may identify one or morelocations that the owner does not wish the vehicle to approach. Thisidentification may be made via one or more interfaces depicted hereinand/or via the user computing device 170. In some embodiments, the ownermay access third party data (such as crime maps) from the third partyremote computing device 164. Regardless, once the locations areidentified and sent to the vehicle computing device 114, the vehiclecomputing device 114 may communicate with the vehicle GPS to determinewhether the vehicle 102 is approaching one of the predeterminedlocations. If the vehicle computing device 114 determines that thevehicle 102 is approaching one of the predetermined locations, thevehicle computing device 114 may send a notification and/or performother action described above.

Another option that may be provided within the parental controls option1470 is an option for smart monitoring occupancy detection. Morespecifically, embodiments disclosed herein may be configured to remotelymonitor the number of occupants in the vehicle 102. If the vehicle 102detects that the number of occupants exceeds a predetermined threshold,an alert may be sent from the vehicle 102, such that it is received bythe owner of the vehicle (e.g., the parent). Depending on the particularembodiment, the vehicle 102 may send an email, SMS message, social mediamessage, telephone call, etc. Similarly, some embodiments may beconfigured to disable one or more aspects of the vehicle (e.g., thevolume of the radio), if the number of occupants exceeds the threshold.In some embodiments, the vehicle may be configured with a camera in theinterior of the vehicle 102, such that if the occupancy level exceedsthe threshold, a picture is automatically taken and sent to the owner ofthe vehicle 102. In some embodiments, an audible alert is provided tothe occupants of the vehicle 102.

As another example, the parental controls option 1470 may be configuredto provide options for the owner of the vehicle 102 to remotely monitorerratic movement of occupants of the vehicle 102. More specifically, theowner may be notified via SMS, email, telephone, etc., when theoccupants of the vehicle are moving erratically. A seat detector in thevehicle 102 may detect the erratic movement and, if the erratic movementexceeded a predetermined threshold for intensity and/or frequency, theowner and/or occupants may be notified.

Yet another example of options that may be provided within the parentalcontrols option 1470 is a smart monitoring seat belt detection option.Similar to the embodiments described above, the vehicle computing device114 may communicate with the seatbelt sensor and/or occupancy sensor todetermine whether the users of the vehicle are using seatbelts. If thevehicle computing device 114 determines that one or more of the vehicleusers is not using their seatbelt, a notification may be sent and/orother actions may be performed. As may also apply to the embodimentsabove, in some embodiments, vehicle functionality may be enabled (e.g.,interior camera) or disabled (e.g., radio volume), upon determiningseatbelts are not fastened.

Also included are options for smart monitoring text detection. As anexample, the owner of a vehicle may be provided with options for remotealerts (e.g., SMS, email, telephone calls, etc.) when one or moreoccupants in the vehicle are texting or otherwise utilizing a mobiledevice. Similarly, functionality in the vehicle may be enabled and/ordisabled, as described above.

As an example, the communication device may receive cellular and/or datacommunications that are identified as a text originating from a user inthe vehicle 102. This determination may be sent to the vehicle computingdevice, which may then communicate with one or more other input/outputhardware 108 to alter the functionality as desired by the vehicle owner.

Also included are options for monitoring volume detection of a vehicle.As an example, embodiments disclosed herein may be configured foralerting the owner or occupant, enabling functionality, and/or disablingfunctionality of the vehicle 102 when a determination is made that thevolume of the vehicle 102 exceeds a predetermined threshold. As anexample, if the volume sensor determines that the volume inside thevehicle reaches a predetermined threshold, a signal may be sent to thevehicle computing device 114. The vehicle computing device may thenfacilitate altering functionality of the vehicle 102, as describedabove.

It should be understood that while the embodiments described above maybe universal for all users of the vehicle 102, this is merely anexample. In some embodiments, an identification of the users of thevehicle may be determined and the above-described functionality may beimplemented based on the current users of the vehicle 102. Otherembodiments are also contemplated.

FIG. 15 depicts a vehicle preference interface 1500 for providingoptions for preferred fuel station brands, according to embodimentsdisclosed herein. The vehicle preference interface 1500 may be providedin response to selection of the fuel stations option 1462 in FIG. 14.More specifically, a plurality of fuel station brands are listed asbeing preferred fuel station brands for the user. The preferred fuelstation brands may be determined by the user manually inputting thepreferred fuel station brands directly into the vehicle computing device114, the user computing device 170, and/or other computing device.Similarly, the preferred fuel station brands may be determined based onuser actions.

Upon selection of the automatic determination option 1550, the vehiclecomputing device 114 may make determinations based on the user actions.As an example, if the user stops at an ABC fuel station (once or morethan once), the vehicle computing device 114 may determine that thisparticular fuel station is preferred and/or this fuel station brand is apreferred fuel station brand.

More specifically, depending on the embodiment, a user may prefer aspecific type of fuel station, such as XYZ brand fuel. The user may alsoprefer a particular fuel station location, such as the XYZ station onMain Street, but does not necessarily prefer all XYZ fuel stations. Assuch, embodiments disclosed herein may be configured to receive a userdesignation (or action) indicating either that the user has a preferredfuel station (or other way-point) brand or whether the user prefers aparticular fuel station (or way-point). As a consequence, embodimentsdescribed herein that refer to a way-point brand may alternatively (oradditionally) include an option for a particular way-point.

Similarly, the user may select an add more option 1552 and/or editoption 1554 to manually input the preferred fuel stations. Also includedis an edit option 1556, which indicates when the user wishes to refuel.As with other options disclosed herein, the vehicle computing device 114may determine the desired refuel level, based on past user actions. Morespecifically, the user can input “30 miles” to indicate that the usergenerally wishes to begin looking for refueling stations when thevehicle determines that there is about 30 miles worth of fuel left. Thevehicle computing device 114 may then receive a signal from the fuellevel sensor that indicates an approximate fuel level. The vehiclecomputing device 114 can additionally estimate the current fuelconsumption and then calculate an estimated distance that the vehiclecan travel before running empty on fuel.

FIG. 16 depicts another vehicle preference interface 1600 for providingoptions for preferred restaurant brands, according to embodimentsdisclosed herein. The vehicle preference interface 1600 may be providedin response to a user selection of the restaurants option 1464 from FIG.14. As illustrated, the user may have preferred restaurants and/orrestaurant brands listed in the vehicle preference interface 1600. Thesepreferred restaurants and/or restaurant brands may be categorizedaccording to meal or other designation. Also provided in the vehiclepreference interface 1600 is an edit times option 1650. The edit timesoption 1650 may provide the user with options to designate times thatthe user prefers to eat various meals. With this information, thevehicle computing device 114 may determine a location that the vehicle102 may be when the preferred meal time arrives. This can allow thevehicle computing device 114 to suggest restaurants and/or scheduleaction items around these designated times.

Also included in the vehicle preference interface 1600 are add options1652 a, 1652 b, and 1652 c (collectively “1652”), edit options 1654 a,1654 b, and 1654 c (collectively (1654)), and turn off auto options 1656a, 1656 b, and 1656 c (collectively “1656”). The add options 1652 mayprovide the user with options to add additional preferred restaurantsand/or restaurant brands. Selection of the edit options 1654 providesoptions to edit existing preferred restaurants and/or restaurant brands.Selection of the turn off auto options 1656 deactivates the automaticdetermination of the preferred restaurant and/or restaurant brands. Morespecifically, the vehicle computing device 114 may be configured todetermine when a user stops and/or orders from a restaurant. The vehiclecomputing device 114 may then determine whether that restaurant and/orrestaurant brand should be identified as a preferred restaurant and/orrestaurant brand.

As an example, the user may enter a destination to the vehicle computingdevice 114. Based on the current location as determined by the vehicleGPS, the destination as entered by the user or determined by the vehiclecomputing device, the current time, and the current speed, the vehiclecomputing device 114 may determine an approximate location that thevehicle 102 will reach at the meal time. The vehicle may then determinewhether there are preferred restaurant brands in that location. If so,the vehicle computing device 114 may also access third party data fromthe third party remote computing device 164 to determine when thatrestaurant will be open

FIG. 17 depicts a vehicle weather interface 1700 for providing analternate routing option, according to embodiments disclosed herein.More specifically, users often do not turn on vehicle routing when theyare traveling to a known location. As such, oftentimes, the user isunaware of the most efficient route to that destination. Embodimentsdisclosed herein however may be configured to monitor destinations,weather, traffic, road conditions, etc. to suggest alternate routes thatmay be more efficient. As an example, a user may consistently leave homearound 8:00 AM for work and take a similar route each day. The vehiclecomputing device 114 may utilize the vehicle GPS to determine and storethe route taken. When the user again begins a similar route the nextmorning at approximately 8:00, the vehicle computing device 114 mayrecognize this common action. Thus, the vehicle computing device 114 maypredict this route that the user is again taking the route to reach theusual destination. Because of this determination, the vehicle computingdevice 114 may suggest alternate routes, based on expected travel time,average speed, weather, traffic, road conditions, etc. Depending on theparticular embodiment, the expected data may be retrieved from the thirdparty remote computing device 164 and/or calculated locally.Accordingly, the vehicle weather interface 1700 may provide the userwith an alternate route option 1750 for accepting the alternate route.Also included is a decline option 1752 for not implementing thealternate routing.

It should be understood that while weather prompted the vehicle weatherinterface 1700, this is merely an example. In some embodiments thevehicle computing device 114 may simply determine that a more efficientroute may be taken. Similarly, other data may trigger the suggestion ofan alternate route, including news, traffic, road conditions, etc.

FIG. 18 depicts a vehicle fuel reminder interface 1800 for providing arouting option to a way-point, such as a fuel station, according toembodiments disclosed herein. As illustrated, the vehicle computingdevice 114 determined that the vehicle 102 is currently traveling toDestin, Fla. This determination may be made due to the user enteringthis destination into the vehicle computing device 114, from previousdestinations, and/or from the vehicle computing device 114 accessingevents on the user schedule. Regardless, by predicting and/ordetermining the desired destination and the current fuel consumption,the vehicle computing device 114 can predict a likely location where thevehicle 102 will deplete the fuel reserves. The vehicle computing device114 may additionally utilize the designated settings (such as in FIG.15) and the vehicle GPS to determine when the user will wish to refuel,as well as locate preferred fuel station brands in that area. Thevehicle fuel reminder interface 1800 may thus provide a routing option1850 for routing to one or more fuel stations. In response to selectingthe routing option 1850, the vehicle computing device 114 may providerouting to the most desirable fuel station and/or provide anotherinterface with options for the user to select among a plurality ofpotential fueling stations in that area.

FIG. 19 depicts a vehicle restaurant reminder interface 1900 forproviding a routing option to a way-point, such as a restaurant,according to embodiments disclosed herein. Similar to the vehicle fuelreminder interface 1800, the vehicle restaurant reminder interface 1900may be configured to recommend restaurants that will be in the vicinityof the vehicle 102 during a predetermined meal time. More specifically,the vehicle computing device 114 may utilize the vehicle GPS todetermine a likely destination for the vehicle 102. Additionally, thevehicle computing device 114 may utilize the current location, currentspeed, destination, and/or other data to determine a likely area thatthe vehicle 102 will reach during the next meal time, as specified inFIG. 16. Based on this information, the vehicle computing device 114 mayutilize the current time, the current location, the destination, and theapproximate speed to determine which of the preferred restaurants and/orrestaurant brands will be within that area. As illustrated, the vehiclerestaurant reminder interface 1900 indicates that three restaurants arelocated in that area and provides a predicted time that the vehicle 102will reach those restaurants, taking into account vehicle speed,traffic, weather, road conditions, etc. between the vehicle 102 and eachrestaurant. Thus, the user may select one of the determined restaurantsin options 1950, 1952, or 1954. By selecting a find others option 1956,the vehicle computing device 114 may locate other restaurants that arepreferred restaurant brands. Selection of a decline option 1958 mayreturn to the vehicle menu interface 600 from FIG. 6.

It should be understood that with regard to the examples of FIGS. 18 and19, the vehicle computing device 114 may further filter results ofpotential restaurants and/or fuel stations, based on other factors, suchas operating hours and price. Instead of (or in addition to) specifyinga fuel station brand, the user may specify a fuel price threshold. Thus,when determining the potential fuel stations for FIG. 18, the vehiclecomputing device 114 may access third party data from the third partyremote computing device 164 to determine the price fuel is being soldfrom those fuel stations. Those fuel stations that exceed the pricethreshold may be filtered out of the results provided in FIG. 18.

Similarly, the vehicle computing device 114 may determine hours ofoperation of the way-point to determine whether the way-point will beopen when the vehicle 102 reaches that location. Again, the vehiclecomputing device 114 may access third party data to determine hours ofoperation for the way-points that meet the criteria described withregard to FIGS. 18 and 19. Based on an expected time of arrival to thoseway-points, the vehicle computing device 114 may determine whichway-points will be operational at that time. The vehicle computingdevice 114 may filter out the way-points that will not be operational atthat time.

FIG. 20 depicts a vehicle way-point interface 2000 for providing a useroption to add a way-point as a preferred restaurant brand, according toembodiments disclosed herein. As illustrated, the vehicle computingdevice 114 may utilize the vehicle GPS to determine whether the vehicle102 stops at a restaurant, fuel station, service station, grocery store,and/or other way-point. In response to this determination, the vehiclecomputing device 114 may determine if the user wishes to add theway-point to one of the preferred way-points and/or preferred way-pointbrands. If so, the user may select a confirm option 2050. If not, theuser may select a decline option 2052.

It should be understood that while the vehicle fuel reminder interface1800 and the vehicle restaurant reminder interface 1900 are depicted asspecific way points, these are merely examples. More specifically, anytype of preferred way-point may be designated.

While the embodiments described above relate to in-vehicle interfaces,these are merely examples. More specifically, FIGS. 21-28 are related toweb interfaces that may be provided via the user computing device 170.It should be understood, however, that the functionality provided in thevehicle interfaces may be provided in the web interfaces and vice versa.

FIG. 21 depicts a web vehicle sign-in interface 2100 for providingvehicle information, according to embodiments disclosed herein. Asdiscussed above, the user computing device 170 and/or the mobile phonedevice 166 may be configured to access data from the remote computingdevice 162 via the internet and/or other wide area network. Morespecifically, in response to accessing a desired wide area networkportal, the web vehicle sign-in interface 2100 may be provided. The webvehicle sign-in interface 2100 may include a vehicle make option 2150 a,a vehicle model option 2150 b, a vehicle year option 2150 c, a useridentification option 2150 d, and a password option 2150 e. The user mayaccess the web vehicle sign-in interface 2100 and submit the requestedinformation. For setting up and/or managing functional and/ornon-functional aspect settings of the vehicle 102 and/or other vehicle.The user may select a submit option 2152 to proceed.

FIG. 22 depicts a web vehicle options interface 2200 for selecting oneor more options for the vehicle 102, according to embodiments disclosedherein. In response to selecting the submit option 2152 from FIG. 21,the remote computing device 162 may provide the web vehicle optionsinterface 2200, which includes a functional aspects option 2250, acalendar option 2252 for viewing a user calendar, a nonfunctionalaspects option 2254, and an other option 2256.

FIG. 23 depicts a web vehicle settings interface 2300 for providingoptions to one or more functional aspects of the vehicle 102, accordingto embodiments disclosed herein. In response to selection of thefunctional aspects option 2250, the web vehicle settings interface 2300may be provided. As illustrated, the web vehicle settings interface 2300may include a seat position option 2350, a language and units setting2352, an avatar option 2354, a minor option 2356, a steering wheeloption 2358, a radio option 2360, an HVAC option 2362, and a previousdestination option 2364. In response to selection of the seat positionoption 2350, the remote computing device 162 may provide seat positionsettings for a driver seat, passenger seat, etc. on the vehicle 102and/or other vehicles.

As described above, these settings may be determined from a useradjusting a seat in the vehicle 102; the user manually inputting seatsettings into the vehicle computing device 114; and/or the user manuallyinputting the seat settings into the remote computing device 162, suchas via a web interface provided by the user computing device 170.Additionally, in response to selecting any of the options 2352-2364,other functional aspects of the vehicle 102 may be viewed and/oradjusted. Also included are a non-functional option 2366 and a saveoption 2368.

FIG. 24 depicts another web vehicle settings interface 2400 forproviding options to one more non-functional aspects of the vehicle 102,according to embodiments disclosed herein. In response to selection ofthe non-functional aspects option 2366, non-functional aspects may beprovided. In response to selection of the non-functional aspects option2254 from FIG. 22, the web vehicle settings interface 2400 may beprovided. As illustrated, the web vehicle settings interface 2400includes an images option 2450, a playlists option 2452, a preferredmusic genres option 2454, a schedules option 2456, an action items listoptions 2458, a news option 2460, a restaurants option 2462, a fuelstations option 2464, a weather option 2466, a communications option2468, a parental controls option 2470, and an other option 2472. Morespecifically, the communications option 2468 may provide options relatedto messaging and social media from the vehicle 102, as discussed withreference with FIG. 14. Similarly, in response to selection of theparental controls option 2470, one or more options for remotelymonitoring and/or controlling the vehicle. Additionally, by selectingthe parental controls option 2740, embodiments may be configured toprovide options for setting the pre-set limits that trigger notificationenabling functionality, and/or disabling functionality. As an example,limits may be set for top speed, occupancy level, radio volume,geo-fencing, etc. Additionally, in some embodiments, options forproviding rewards for positive behavior.

FIG. 25 depicts a web vehicle preferred way-point interface 2500 forproviding options for a preferred restaurant brand, according toembodiments disclosed herein. In response to selection of therestaurants option 2462, the web vehicle preferred way-point interface2500 may be provided by the remote computing device 162. As illustrated,the web vehicle preferred way-point interface 2500 includes add options2550 a, 2550 b, and 2550 c (collectively “2550”), edit options 2552 a,2552 b, and 2552 c (collectively (“2552”), and turn off auto options2554 a, 2554 b, and 2554 c (collectively “2554”). The add options 2550allow the user to add additional restaurants and/or restaurant brands tothe preferred restaurants depicted in FIG. 25. The edit options 2552allow the user to edit the restaurants and/or restaurant brands thepreferred restaurants depicted in FIG. 25. The turn off auto options2554 allow the user to deactivate the automatic determination ofpreferred restaurants, based on the vehicle computing device 114receiving a signal from the vehicle GPS indicating that the vehicle 102has arrived at a restaurant.

Also included in the web vehicle preferred way-point interface 2500 aretime edit options 2556 a, 2556 b, and 2556 c (collectively “2556”). Thetime edit options 2556 may be provided the user with options to edit thedesired time for each meal and/or add additional meals. The returnoption 2558 returns the user to the web vehicle settings interface 2400from FIG. 24.

FIG. 26 depicts another vehicle preferred way-point interface 2600 forproviding options for a preferred fuel station, according to embodimentsdisclosed herein. The vehicle preferred way-point interface 2600 may beprovided in response to selection of the fuel stations option 2464. Asillustrated, the vehicle preferred way-point interface 2600 may providepreferred fuel stations and/or preferred fuel station brands. Thevehicle preferred way-point interface 2600 may include a deactivateoption 2650 for deactivating the automatic determination of preferredfuel stations based on a vehicle location. Also included is an add moreoption 2652 for adding additional fuel stations and/or fuel stationbrands and an edit option 2654 for editing the current fuel stationsand/or fuel station brands. An edit option 2656 may be provided forediting the threshold distance that the vehicle 102 can travel beforedepleting the fuel reserves that will trigger refueling reminders.

FIG. 27 depicts a web vehicle schedule interface 2700 for linking aremotely stored user schedule with the vehicle, according to embodimentsdisclosed herein. In response to selection of the schedule option 2456,the web vehicle schedule interface 2700 may be provided. As illustrated,the web vehicle schedule interface 2700 may request whether the userwishes to link a remote schedule with the vehicle 102. Also included area link option 2750 and a decline link option 2752. In response tolinking the remote schedule with the vehicle 102, the vehicle computingdevice 114 may utilize the schedule for event reminders, routing, and/orother actions as described herein.

It should be understood that while FIGS. 26 and 27 depict restaurantsand fuel stations as way-points, these are merely examples. Morespecifically, any type of way-point may be utilized and configured in asimilar manner. Examples include service stations, grocery stores,pharmacies, rest stops, etc.

FIG. 28 depicts a web vehicle weather interface 2800 for providingweather options for the vehicle 102, according to embodiments disclosedherein. In response to selection of the weather option 2466 from FIG.24, the web vehicle weather interface 2800 may be provided. The webvehicle weather interface 2800 may include data regarding weatherconditions that the user has designated as a reason for the vehiclecomputing device 114 to suggest an alternate route. Also included is anedit option 2850 for editing the depicted conditions and options.

While FIGS. 21-28 are directed to web interfaces, FIGS. 29-40 aredirected to various processes that may be performed using the vehiclecomputing device 114. Specifically, FIGS. 29-33 depict processes fordetermining an authorized user, as discussed with regard to the vehicleinterfaces depicted in FIGS. 4, 5, 13-14, and/or 23-25, among others.

FIG. 29 depicts a flowchart for providing customized communication withan authorized vehicle user, according to embodiments disclosed herein.As illustrated in block 2970, user preferences and authorizationinformation relating to a mobile phone device and third party data maybe obtained. In block 2972, a particular user may be recognized uponapproach to a vehicle with the authorized mobile phone device. In block2974, user preferences related to functional and non-functional aspectsof the vehicle may be implemented. In block 2976, customized interactivecommunication with the authorized user based on stored user preferencesand third party information may be provided.

FIG. 30 depicts a flowchart for adjusting functional and/ornon-functional aspects of a vehicle, according to embodiments disclosedherein. As illustrated in block 3070, a signal for access to a vehiclemay be received from a first device. In block 3072, a determination maybe made regarding whether the first device properly authorized access tothe vehicle. If the first device did not provide proper authentication,the process may end. If the first device did provide properauthentication, access may be granted. In block 3074, an identifyingsignal may be received from a second device, where the second device isdifferent than the first device. In block 3076, a determination may bemade regarding whether the authenticating user identifier is storedlocally. If the user identifier is stored locally, in block 3078, theauthenticating user identifying may be retrieved and utilized toimplement one or more functional and non-functional aspects of thevehicle. If the user identifier is not stored locally, in block 3080,the remotely stored information may be retrieved. In block 3082, adetermination may be made regarding whether the user configuration datacorresponds with vehicle capabilities. In block 3084, the userconfiguration data that corresponds with the vehicle capabilities may beapplied to adjust functional and non-functional aspects of the vehicle.

FIG. 31 depicts a flowchart for uploading user preference data from avehicle to a remote computing device, according to embodiments disclosedherein. As illustrated in block 3170, user preferences for a vehicle maybe received. In block 3172, a determination may be made regardingwhether the vehicle currently maintains a network connection. If not, inblock 3174, the data may be stored locally and the process may return toblock 3172. If a network connection is available, in block 3176, userpreference data may be uploaded to a remote computing device.

FIG. 32 depicts a flowchart for implementing a functional and/ornon-functional aspect of the vehicle, according to embodiments disclosedherein. As illustrated in block 3270, a user identify may be identifiedfrom a mobile device. In block 3272, a determination may be maderegarding whether functional and non-functional aspects of the vehicleare stored locally. If so, in block 3274, the functional andnon-functional aspects of the vehicle may be retrieved and implemented.If not, in block 3276, a determination may be made regarding whether thefunctional and non-functional aspects of the vehicle are stored on amobile device. If so, the process may proceed to block 3274. If not, inblock 3278 a determination may be made regarding whether the functionaland non-functional aspects of the vehicle are stored remotely. If so,the process proceeds to block 3274. If not, in block 3280, the useractions may be utilized to predict functional and non-functional aspectsof the vehicle. In block 3282, the functional and non-functional aspectsof the vehicle may be stored and implemented.

FIG. 33 depicts a flowchart for sending user settings to a rentalvehicle, according to embodiments disclosed herein. More specifically,embodiments disclosed herein may be configured for remote storage of thefunctional and/or non-functional aspects of a vehicle, such that whenthe user accesses a second vehicle, such as a rental vehicle, the userpreferences are already applied to the second vehicle. As illustrated inblock 3370, rental data related to a rental agreement for a rentalvehicle may be received and stored, where the rental data includes afirst copy user identifier. As an example, if a user decides to rent avehicle, she may sign up online, place a phone call, and/or visit arental facility. Regardless, the user may provide the requested rentalinformation, as well as a user identifier for accessing her vehiclepreferences.

In block 3372, an identification of the rental vehicle that is subjectto the rental agreement may be received and stored, where some point inthe rental process, a vehicle will be assigned to the user. Depending onthe particular rental company, the vehicle will be assigned when theuser signs the rental agreement or when the user actually retrieves therental vehicle. In block 3374, the user preference data may bedetermined for the user. In block 3376, the user preference data may becompared with vehicle capability date for the rental vehicle todetermine a setting for a functional aspect of the rental vehicle and asetting for a non-functional aspect of the rental vehicle. Morespecifically, the user preference data may be related to the user's ownvehicle or to a generic vehicle. Because the user preference data mayinclude functional and/or non-functional aspects the rental vehicle maynot accommodate, a comparison may be performed to determine whichaspects may be applied to the rental vehicle. In block 3378, thesettings and/or the first copy user identifier may be sent to the rentalvehicle for implementation. More specifically, when the user approachesthe rental vehicle, the user may have a user communication device, suchas the mobile phone device 166. The user communication device may send asecond copy user identifier to the rental vehicle. The rental vehicle(and/or the remote computing device 162 may authenticate the user bycomparing the first copy user identifier and the second copy useridentifier. Upon the user being authenticated, the settings may beapplied to the rental vehicle.

While FIGS. 29-33 describe processes that may be utilized fordetermining functional and non-functional aspects of the vehicle 102,storing and uploading data to a network, and utilizing customizedpreferences for a rental vehicle, FIGS. 34-36 are directed toembodiments for event scheduling and routing. More specifically, FIGS.34-36 describe embodiments that are related to the interfaces depictedin FIGS. 6-12 and/or 27, among others.

FIG. 34 depicts a flowchart for an event reminder, according toembodiments disclosed herein. As illustrated in block 3470, informationrelated to user preferences, a user schedule, and third partyinformation may be obtained. In block 3472, a communication may bereceived directly from a vehicle computing device, the communicationincluding authenticating information for a user. In block 3474, inresponse to authenticating the user, a reminder may be automaticallyprovided for an event on the user schedule a predetermined time prior tothe event.

FIG. 35 depicts a flowchart for providing routing to a predeterminedlocation, according to embodiments disclosed herein. As illustrated inblock 3570, remotely stored schedule information for a user may beretrieved, where the remotely stored schedule information includes anupcoming event that is scheduled at a future time and at a predeterminedlocation. In block 3572, the schedule information may be compared to acurrent time and a current vehicle location. In block 3574, a traveltime to the predetermined location from the current vehicle location maybe calculated. In block 3576, a determination may be made from thetravel time, regarding a preferred time for departure to reach theupcoming event before the future time. In block 3578, a reminder of theupcoming event may be provided at a predetermined time before thepreferred time for departure. In block 3580, driving directions may beprovided to the predetermined location from the current vehiclelocation.

FIG. 36 depicts a flowchart for providing routing information to anaccessory that is related to an event, according to embodimentsdisclosed herein. As illustrated in block 3670, schedule information maybe received by a vehicle for an upcoming event and an event location. Inblock 3672, a determination may be made regarding whether the upcomingevent includes an accessory. If not, at block 3674, routing and/orreminders maybe provided for the upcoming event. If an accessory isassociated with the upcoming event, at block 3676, a determination maybe made regarding whether the accessory is currently located in thevehicle. If so, the process may proceed to block 3674. If the accessoryis not currently in the vehicle, in block 3678, an accessory locationmay be determined for the accessory. As discussed above, the accessorylocation may be determined via a satellite tracking identifier, througha user input, through past user actions, etc. In block 3680, in responseto determining that the accessory is not currently located in thevehicle, an indication may be provided to the user that the accessory ismissing and an option may be provided for routing to the accessorylocation. In block 3682, in response to receiving user input for routingto the accessory location, routing information is provided to theaccessory location and, after the vehicle arrives at the accessorylocation; routing guidance to the event location is provided.

While FIGS. 34-36 are directed to processes for scheduling and/orrouting the vehicle 102 to appointments and/or action items, FIGS. 37-40are directed to embodiments related to determining providers. Morespecifically, FIGS. 37-40 are directed to processes that may beimplemented by the vehicle computing device 114 while utilizing theinterfaces depicted in FIGS. 15-20 25, and/or 26, among others.

FIG. 37 depicts a flowchart for providing a likely point of interestand/or alternate route to a user, according to embodiments disclosedherein. As illustrated in block 3770, a communication may be establishedwith a plurality of third party data storage units. In block 3772, atleast one remotely stored user preference for a vehicle may beretrieved. In block 3774, storage of past locations and/or routestraveled may be facilitated. In block 3776, the past locations and/orroutes traveled may be utilized to predict likely points of interestand/or alternate routes. In block 3778, the likely points of interestand/or the alternate routes may be provided to the user.

FIG. 38 depicts a flowchart for providing vehicle routing to away-point, such as a fuel station, according to embodiments disclosedherein. As illustrated in block 3870, a destination of a vehicle may bedetermined. In block 3872, a fuel level of the vehicle may bedetermined, such as from the fuel level sensor. In block 3874, a fuelconsumption level of the vehicle may be calculated, such as from a fuellevel sensor. More specifically, the vehicle computing device 114 mayreceive fuel level indications from a fuel level sensor and utilize thatinformation over a predetermined time to determine the current fuellevel consumption. In block 3876, a location on the route where the fuellevel will likely pass below a predetermined threshold may bedetermined. This may be determined utilizing the current fuel level, thecurrent fuel consumption, a current location (as determined by thevehicle GPS), and the destination (as determined by the vehicle GPS). Inblock 3878, a preferred fuel station brand may be determined for theuser. In block 3880, a fuel station that is the preferred fuel stationbrand and is within a predetermined distance from the location may bedetermined. More specifically, once the likely area that the vehiclewill run low on fuel is determined, the vehicle computing device canutilize GPS and/or third party data to determine the available fuelproviders in that area. With the available fuel providers, the vehiclecomputing device 114 may determine which of those are one of the user'spreferred fuel station brands. In block 3882, the fuel station may beprovided to the user, as well as an option to route the vehicle to thefuel station. In block 3884, vehicle routing to the fuel station may beprovided to the vehicle, such as via the vehicle GPS.

FIG. 39 depicts a flowchart for providing vehicle routing to away-point, such as a restaurant, according to embodiments disclosedherein. As illustrated in block 3970, a route to a destination may bedetermined for a vehicle, such as via a vehicle GPS. In block 3972, adesired meal time may be determined. As discussed above, the desiredmeal time may be determined via a user input and/or previous useractions. As an example, if the vehicle computing device 114 determinesthat the user generally stops at a restaurant (as indicated by thevehicle GPS) between 6:00 PM and 7:00 PM, the vehicle computing device114 may determine that the user's preferred dinner time is between 6:00PM and 7:00 PM. In block 3974 an approximate speed of the vehicle may bedetermined.

In block 3976, an approximate location for the vehicle at the desiredmeal time may be predicted. As discussed above, based on the currentlocation (as determined by the vehicle GPS), time, destination, andapproximate speed, the vehicle computing device 114 may determine anapproximate destination that the vehicle will reach at the determinedmeal time. In block 3978, a preferred restaurant brand may be determinedfor the user. In block 3980, a restaurant may be determined along theroute that is the preferred restaurant brand and is a distance from thevehicle such that the vehicle would arrive at the restaurant within apredetermined time of the desired meal time. As discussed above, thepreferred restaurant brand may be determined from a user designationand/or via historical user actions. Regardless, once the vehiclecomputing device 114 determines the likely location of the vehicle 102at the determined meal time, the vehicle computing device 114 maydetermine if any restaurants are in that area that are of the preferredrestaurant brand. In block 3982, the restaurant may be provided to theuser, as well as an option to route the vehicle to the restaurant. Inblock 3984, vehicle routing to the restaurant may be provided.

FIG. 40 depicts a flowchart for providing an alternate vehicle route dueto weather, according to embodiments disclosed herein. As illustrated inblock 4070, a route for a vehicle may be determined. In block 4072, anapproximate speed for the vehicle may be determined, such as using thevehicle speedometer. In block 4074, weather condition data along theroute may be determined. More specifically, the vehicle GPS and/orvehicle computing device 114 may determined as described above. Thevehicle computing device 114 may additionally access the third partyremote computing device 164 to access weather data at one or more pointsbetween the current location of the vehicle 102 and the destination. Adetermination may additionally be made by the remote computing device114 regarding whether there are any weather conditions along the routethat would affect travel to the destination. In block 4076, in responseto determining that the weather conditions will affect the vehicle, anindication of the weather conditions may be provided to the user, aswell as a user option for providing an alternate route for the vehicle.In block 4080, in response to receiving user input, the alternate routemay be provided to the user.

As illustrated above, various embodiments for providing user access to avehicle; providing a vehicle smart calendar; and determining availableproviders are disclosed. As a consequence, embodiments disclosed hereinmay be configured to uniquely identify a user that is accessing avehicle, regardless of who the primary driver of that vehicle is.Additionally, because the vehicle may be configured to communicatedirectly with a remote computing device (cloud storage device), aremotely stored user schedule may be accessed by the vehicle withoututilizing a bridging device, such as a mobile phone using a mobilenetwork. Because of this, embodiments may be configured to easilyprovide user events and action items, as well as provide dynamic routingbased on third party data, such as weather, traffic, road conditions,etc. Further embodiments may also be configured to predict a destinationwithout the user turning on a routing function in the vehicle. Becauseof this, the vehicle may be able to determine whether a more efficientroute is available to the user without the user having to manuallyactivate the routing function in the vehicle. Additionally, someembodiments may be configured to determine preferred way-points along aroute and predict the next stopping point for the vehicle. As someembodiments may utilize third party data, such as price data, operatinghours, etc., the user will not risk searching for a way-point in an areawhere none are available. Other embodiments are also described.

While particular embodiments and aspects of the present disclosure havebeen illustrated and described herein, various other changes andmodifications can be made without departing from the spirit and scope ofthe disclosure. Moreover, although various aspects have been describedherein, such aspects need not be utilized in combination. Accordingly,it is therefore intended that the appended claims cover all such changesand modifications that are within the scope of the embodiments shown anddescribed herein.

It should now be understood that embodiments disclosed herein includessystems, methods, and non-transitory computer-readable mediums forestimating a temperature calibration. As discussed above, suchembodiments are configured to determine a dynamic smoothing value, whichmay be based on vehicle speed, coolant temperature, and/or othercriteria. It should also be understood that these embodiments are merelyexemplary and are not intended to limit the scope of this disclosure.

What is claimed is:
 1. A method for determining available providers to avehicle user comprising: communicating with a plurality of third partydata storage units, at least one of the plurality of third party datastorage units comprising user preference data for a vehicle; retrievingthe user preference data from a remote location, the user preferencedata comprising a user calendar entry for a user; facilitating storageof the user preference data; determining whether the calendar entryincludes an event that utilizes an accessory; determining a location ofthe accessory; determining a direction of a current route; utilizing theuser preference data, the user calendar entry, the location of theaccessory, and the current route to predict a likely currentdestination; and providing, by a vehicle computing device, data relatedto the likely current destination to the user.
 2. The method of claim 1,further comprising utilizing a current vehicle path with the userpreference data to predict the likely current destination.
 3. The methodof claim 1, further comprising utilizing data from the plurality ofthird party data storage units to determine whether an alternate routeto the likely current destination is available; and providing thealternate route to the likely current destination.
 4. The method ofclaim 1, wherein data related to the likely current destinationcomprises at least one of the following: an identification of the likelycurrent destination; and routing data for reaching the likely currentdestination.
 5. The method of claim 1, wherein the user preference datafurther comprises a preferred way-point brand.
 6. The method of claim 5,further comprising: determining that the preferred way-point brandcomprises a preferred fuel station brand; predicting, from a currentfuel level, a current vehicle position, and the likely currentdestination, a potential location for refueling the vehicle;determining, from the plurality of third party data storage units, afuel station that comprises the preferred fuel station brand and that iswithin a predetermined distance of the potential location for refuelingthe vehicle; and providing a user notification regarding the fuelstation.
 7. The method of claim 1, further comprising: determining thatthe preferred way-point brand comprises a preferred restaurant brand;predicting from a current time, a current position, and the likelycurrent destination, a potential location for patronizing; determiningfrom the plurality of third party data storage units, a restaurant thatcomprises the preferred restaurant brand and that is within apredetermined distance of the potential location for patronizing; andproviding a user notification regarding the restaurant.
 8. A system fordetermining available providers comprising: a memory component thatstores logic that, when executed by a computing device, causes thecomputing device to perform at least the following: receive a userindication of a predetermined threshold for refueling; determine acurrent route of a vehicle; determine a destination of the vehicle,based on the current route and a user calendar entry received from aremote device; determine a fuel level of the vehicle at a current time;determine, from the destination and the fuel level at the current time,an approximate location that the fuel level will pass below thepredetermined threshold; determine a preferred fuel station brand for auser; determine a fuel station that is the preferred fuel station brandand is within a predetermined distance from the approximate location;provide the fuel station to the user and an option to route the vehicleto the fuel station; and provide vehicle routing data to the fuelstation.
 9. The system of claim 8, wherein the destination is determinedfrom at least one of the following: as a prediction based on previousdestination data and a current vehicle path; and from a user inputindicating the destination of the vehicle.
 10. The system of claim 8,wherein determining the fuel station further comprises: determining alikely time that the vehicle will reach the approximate location; anddetermining whether the fuel station operates at the likely time. 11.The system of claim 8, wherein the logic further causes the system tocalculate a fuel consumption of the vehicle.
 12. The system of claim 8,wherein the logic further causes the system to perform at least thefollowing: generate a user interface for providing the preferred fuelstation brand; and provide a user option to edit the preferred fuelstation brand.
 13. The system of claim 8, wherein the logic furthercauses the system to perform at least the following: access a thirdparty data, the third party data comprising at least one of thefollowing: weather data, traffic data, and road condition data; andaltering the approximate location based on the third party data.
 14. Thesystem of claim 8, wherein the logic further causes the system toperform at least the following: determine that a current vehiclelocation is in proximity of a new fuel station; and provide a useroption to add the new fuel station as the preferred fuel station brand.15. A vehicle for determining available providers to a vehicle usercomprising: a vehicle computing device that stores logic that, whenexecuted by the vehicle computing device, causes the vehicle computingdevice to perform at least the following: receive a future desired mealtime for a plurality of meals of a particular meal type; determine acurrent route of the vehicle; determine a destination of the vehicle,based on the current route; determine a continued route to thedestination for the vehicle; determine an approximate speed of thevehicle to the destination; predict an approximate location that thevehicle will reach the future desired meal time; determine, from aprevious vehicle stop, a preferred restaurant brand for the user;determine a restaurant along the route that is the preferred restaurantbrand and is at a distance from the vehicle such that the vehicle willarrive at the restaurant within a predetermined time of the desired mealtime, as determined from the approximate speed; provide the restaurantto the user and an option to route the vehicle to the restaurant; andprovide vehicle routing to the restaurant.
 16. The vehicle of claim 15,wherein the preferred restaurant brand includes at least one of thefollowing: a breakfast restaurant brand, a lunch restaurant brand, and adinner restaurant brand.
 17. The vehicle of claim 15, wherein thedestination is determined from at least one of the following: as aprediction based on previous destination data and a current vehiclepath; and from a user input indicating the destination of the vehicle.18. The vehicle of claim 15, wherein the logic further causes thevehicle computing device to perform at least the following: determininga likely time that the vehicle will reach the restaurant; anddetermining whether the restaurant operates at the likely time.
 19. Thevehicle of claim 15, wherein the logic further causes the vehiclecomputing device to perform at least the following: determine that acurrent vehicle location is in proximity of a new restaurant; andprovide a user option to add the new restaurant as the preferredrestaurant brand.
 20. The vehicle of claim 15, wherein the logic furthercauses the vehicle computing device to perform at least the following:access a third party data, the third party data comprising at least oneof the following: weather data, traffic data, and road condition data;and altering the approximate location based on the third party data.